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Abstract 


This document describes the SPIRITS protocol requirements, based on 
the architecture presented in RFC 3136. (SPIRITS stands for "Service 
in the PSTN/IN Requesting InTernet Service".) The purpose of the 
protocol is to support services that originate in the Public Switched 
Telephone Network (PSTN) and necessitate the interactions between the 
PSTN and the Internet. Similarly, such services are called SPIRITS 
services. (Internet Call Waiting, Internet Caller-ID Delivery, and 
Internet Call Forwarding are examples of SPIRIT services, but the 
protocol is to define the building blocks from which many other 
services can be built.) On the PSTN side, the SPIRITS services are 
initiated from the Intelligent Network (IN) entities; the earlier 
IETF work on the PSTN/Internet Interworking (PINT) resulted in the 
protocol (RFC 2848) in support of the services initiated the other 
way around--from the Internet to PSTN. 


To this end, this document lists general requirements for the SPIRITS 
protocol as well as those pertinent to IN, Wireless IN, and PINT 
building blocks. The document also presents the SPIRITS WG consensus 
on the choice of the SPIRITS signaling protocol. 
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1. Conventions used in this document 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in RFC 2119. 


Unless otherwise qualified, the term PINT is used here not to refer 
to the present PINT services and protocol, but in reference to the 
scope of the generic PINT (vs. SPIRITS) service characteristics-- 
services being invoked from an IP network (vs. PSTN). 


2. Introduction 


This document describes the SPIRITS protocol requirements, based on 
the architecture presented in RFC 3136. (SPIRITS stands for "Service 
in the PSTN/IN Requesting InTernet Service.") The purpose of the 
protocol is to support services that originate in the Public Switched 
Telephone Network (PSTN) and necessitate the interactions between the 
PSTN and the Internet. Such services are called SPIRITS services. 
(Internet Call Waiting, Internet Caller-ID Delivery, and Internet 
Call Forwarding are examples of SPIRIT services, but the protocol is 
to define the building blocks from which many other services can be 
built.) On the PSTN side, the SPIRITS services are initiated from 
the Intelligent Network (IN) entities; the earlier IETF work on the 
PSTN/Internet Interworking (PINT) resulted in the protocol (RFC 2848) 
in support of the services initiated the other way around--from the 
Internet to PSTN. 


To this end, this document lists general requirements for the SPIRITS 
protocol as well as those pertinent to IN, Wireless IN, and PINT 
building blocks. The document also presents the SPIRITS WG consensus 
on the choice of the SPIRITS signaling protocol. The joint 
PINT/SPIRITS architecture (described in [1]) is depicted in Figure 1. 


It is assumed that the Spirits Client is either co-located with the 
IN Service Control Function (SCF) or communicates with it (over the 
PSTN-specific interface D) in such a way so as to act on behalf of 
the PSTN/IN. (This assumption is confirmed by current 
implementations, as reported in [2].) 


The SPIRITS services are invoked (and, subsequently, the SPIRITS 
protocol is initiated) when a message from a SPIRITS Client (located 
in the IN Service Control Point [SCP] or Service Node [SN]) arrives 
on interface C to the SPIRITS gateway. The Spirits gateway processes 
the message and, in turn, passes it on over the Interface B to the 
SPIRITS server. In most practically important cases, the request 
from a SPIRITS client is ultimately caused by a request from a 
Central Office (i.e., a telephone switch) sent to either the SCP or 
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SN, although the Internet-based service initiation by these elements 
that had not been triggered by the Central Office is theoretically 
possible. (Definitely, none of the SPIRITS benchmark services are 
initiated in such a way, so, for the purposes of the SPIRITS protocol 
development, it should be assumed that the service invocation was a 
direct result of an earlier action by the Service Switching 
Function.) 
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Figure 1. Joint PINT/SPIRITS Architecture 
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With PINT (and that also applies to the PINT architecture and 

protocol as described in [3]), the service request to the PINT Server 
is always initiated by the PINT Client over the interface A. The PINT 
Server can either be co-located with the IN Service Control or a 
similar entity (referred to as "Executive System" by [3]) or 
communicate with it over the PSTN-specific interface E. 


As Figure 1 shows, the PINT Client and SPIRITS Server are co-located 
in Subscriber’s IP Host. In fact, both can be implemented to run as 
one process. No provision is made for interactions between the PINT 
Client and Spirits Server. Similarly, the PINT Server/PINT Gateway 
and SPIRITS gateway are assumed to be co-located, too. This 
assumption is convenient but not essential; the PINT Server could 
also be co-located with the SPIRITS Client. In either case, no 
specific provision is made to define interworking between either the 
PINT Server and Spirits Gateway or PINT Server and SPIRITS Client 
other than by listing the overall PINT-related requirements. 


Since the currently deployed worldwide wireless networks are based on 
circuit switching, they are considered PSTN networks for the SPIRITS 
purposes. Adding SPIRITS type of services to wireless networks can 
allow new services to be developed (for example geolocation 
information can be handled in the IP network). 


Nevertheless, there are certain peculiarities of wireless networks, 
which force considerations to be made in the protocol 
requirements and in the SPIRITS architecture. 


A particular Wireless IN standard development being considered here 
is CAMEL phase 3, standardized by the Third Generation Partnership 
group (3GPP). The relevant service and architectural considerations 
and protocol requirements are presented later in this document. As 
far as the architecture is concerned, certain wireless events are 
generated by Home Location Register (HLR), which may, but does not 
have to, be part of the Mobile Switching Center (MSC) (a wireless 
equivalent of the SSP). These events are communicated to Service 
Control, at which point they use the same mechanism for invoking 
SPIRITS services that the IN would. 


The rest of this document addresses the general requirements, 

IN Requirements, specific Wireless IN requirements, PINT 
Requirements, the protocol development methodology, and security 
issues, in that order. 
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3. General Requirements 


Based on the success of extending SIP for PINT ([3]) and, especially, 
the results of pre-SPIRITS implementations reported in [2], the 
Session Initiation Protocol (SIP) [7] has been chosen as the 
signaling base protocol for SPIRITS. 


Thus, it is a requirement that specific SPIRITS-related parameters be 
carried in a manner consistent with SIP practices. In particular, 
either Session Description Protocol (SDP) [8] or Multi-purpose 
Internet Mail Extensions MIME [5-6] may be used for this purpose. 
Except for the proposed new SUBSCRIBE/NOTIFY mechanism [4], and 
extensions already defined in PINT, no new SIP extensions are 
foreseen; instead the SPIRITS protocol is to rely on the above 
extension mechanisms. 


It is by no means a requirement that any SPIRITS implementation 
automatically support PINT services. The SPIRITS protocol must be 
defined in a manner where, as the minimum, it can support only the 
basic notification mechanism without relying on PINT services or 
otherwise relying on persistent interactions with PSTN. 

Nevertheless, it has been demonstrated [2] that combining PINT 
building blocks with those of SPIRITS is beneficial to building rich, 
enhanced PSTN/Internet services, so the SPIRITS protocol must meet 
the PINT-related requirements listed in section 7 of this document. 


One specific example demonstrating the application of the latter 
requirement, which is elaborated on further in this document, is as 
follows: Implementation of SUBSCRIBE/NOTIFY is not mandatory as far 
as the minimum SPIRITS protocol is concerned. Thus, the initial PSTN 
(Detection Point) notification will always arrive via the SIP INVITE 
method; however, to implement persistent interactions with the PSTN, 
the SUBSCRIBE method may be used to obtain further notifications of 
the PSTN events. Subsequently, these events will be reported on by 
means of the NOTIFY method. 


4. IN Requirements 
The interface immediately relevant to IN is that between the SPIRITS 
Client and SPIRITS Gateway (interface C). A typical message (which 
starts a SPIRITS service) looks like this: 
C -> G: <Event Notification>, <Parameter-List (DP)> 
The relevant events correspond to the detection points (DPs) of the 
IN Basic Call State Model (BCSM). The <Parameter-List> is a function 


of a specific DP; it contains the parameters relevant to it. The 
following requirements apply: 
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1) 


The list of the DPs to be covered encompasses those defined in the 
IN Capability Set 3 BCSM as well as those which relate to the 
Wireless IN (WIN) specified by the IMT 2000 project in ITU-T. 


Not all parameters associated with such DPs are needed by the 
SPIRITS benchmark services, nor may all the parameters be needed 
in SPIRITS. The selection of the relevant parameters is part of 
the SPIRITS protocol definition. 


It is desirable to avoid semantic overload of protocol messages. 
(One way to achieve that is to match each type of an event with a 
message that corresponds to it.) As the SPIRITS protocol is 
designed as a set of extensions to another (existing) protocol 
with the defined message set, the syntax and semantics of the 
extensions should be defined with this requirement in mind. 


The ITU-T Recommendations use the abstract syntax notation (ASN.1) 
to specify the semantics of the IN Application Protocol (INAP) 
parameters, which are expected to be binary-encoded. Neither the 
use of the ASN.1, nor the requirement for binary encoding are the 
typical requirements for the IETF application protocols. 
Recognizing that, provisions must be made for careful 
specification of the conversion of the INAP parameters to text, 
which must preserve their original semantics. The actual 
conversion of the parameters is the function of the SPIRITS 
Client. 


In order to issue an initial query (or a notification) to service 
control, a switch must have such a DP set. This can be done 
statically via service management (this particular action should 
be left to implementation and thus is considered outside of the 
scope of SPIRITS Protocol) or dynamically--but only for the 


purpose of a particular call--from the service control. In the 
latter case, it is part of the SPIRITS (or PINT) protocol to 
request the event notification from the service control. The SIP 


specific event notification scheme [4] should be specifically 
considered. This function can be performed by either the Spirits 
Client or PINT Server, the distinction being further discussed in 
the next section. Assuming that it is performed by the SPIRITS 
Client, the relevant message should look like: 


G->C: SUBSCRIBE <Event> <Mode> <DP-specific parameters>, 


where <Event> refers to a particular DP; <Mode> determines whether 
the Event Detection Point (EDP) is to be armed as EDP Request 
(EDP-R), EDP Notification (EDP-N), or TDP-R (the need for TDP-N is 
not foreseen because it would not provide any additional 
capability for SPIRITS); and the <DP-specific parameters> is the 
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list of the values of the parameters associated with the EDP (for 
example, if the DP in question is O No Answer, then the value of 
the appropriate timer should be included in the list). Note that 
such a subscription may also originate at a) PINT Client or b) 
SPIRITS Gateway, either of which may (but does not have to) have a 
locally significant definition of the <Event>. In either case, it 
is the function of the SPIRITS Client to translate the definition 
of the Event into a particular DP (or set of DPs) when passing the 
message to Service Control. To summarize, for the case when PINT 
and SPIRITS events are defined in a way where they do not refer to 
the BCSM DPs, it is the function of the SPIRITS Client to define a 


mapping: 

Event -> DP List, 

for each event for which the PSTN notification is needed. 
The list of CS-3 DPs envisioned in SPIRITS is: 


- origination attempt authorized (the SPIRITS service can control 
call attempts, (for example, to limit calls during specific 
time periods) 


- collected_information and analyzed information (for SPIRITS 
outgoing call screening) 


- o answer, o term seized, and t answer (to release SPIRITS 
resources after the call is complete and perform relevant OA&M 
actions such as creating a record of attempts to reach a party 
via various means like land-line phone, cell phone, SMS, or 


paging.) 


- o_no_answer, route select failure, and t no answer (to re-route 
a call) 


- o called party busy (to re-route a call and for Internet Call 
Waiting) 


- o mid call and t mid call (to assist a midcall action) 


- o_abandon, o_disconnect, t abandon, and t disconnect (to 
terminate a SPIRITS service and release the resources and 
perform relevant OA&M actions such as creating a record of 
attempts to reach a party via various means like land-line 
phone, cell phone, SMS, or paging.) 
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In addition, the following DPs are relevant to the present SPIRITS 
milestone services: 


- termination attempt authorized 


- facility selected and available (could be used in SPIRITS 
Internet Caller-ID) 


- t busy (for Internet Call Waiting and Call Forwarding). 
5. Wireless-IN-related Requirements 


Wireless IN covers several types of "calls," which are neither 
circuit switched nor have an effect on circuit switched calls. For 
this reason, those are not considered in SPIRITS requirements. To 
further clarify this point, the types of "calls" not considered are: 


- USSD (Unstructured Supplementary Service Data) 
- GPRS (General Packet Radio System) 
- SMS (Short Message System) 
The types of calls relevant to SPIRITS are as follows: 


a) Voice Calls. In this case no new DP is needed since CAMEL DPs 
are included in CS2. The only special case is "Not Reachable" 
(when it is detected that the mobile user is out of coverage or 
has switched off), which is mapped as a special cause in the 
Busy DP. Since the Busy DP parameters would be received (if a 
SPIRITS service has subscribed to Busy), it would be possible 
to distinguish a "busy" from a "not reachable" situation. 


This translates into the requirement that one of the parameters 
in the Event Notification message (from SPIRITS Client to 
SPIRITS Gateway, over the interface C) denotes the "cause" for 
the Busy Detection Point. 


Another aspect of difference, when compared to PSTN, is setting 


of static DPs. In CAMEL networks, this is done in the Home 
Location Register (HLR) (and copied to the VLR during location 
update). It is important to note this difference, even though 


it has no effect on SPIRITS protocol. 
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b) Mobility Management events. This allows a SPIRITS server to be 
notified of changes of location of a mobile user. The events 
would only be applicable to mobile users reachable through a 
Circuit-Switched network. To provide for this function, the 
subscription marks must be set in the subscriber’s HLR. This 
is equivalent to setting TDPs in the SSP. In this case, the 
marks in the HLR (which are copied to the Visitor Location 
Register [VLR] on location update) are not mapped into Trigger 
Detection Points. 


As with TDP setting, this is outside of the scope of SPIRITS 
protocol. 


In order to support this function in SPIRITS, the SPIRITS 
protocol should be able to map the CAMEL specific operations 
into events notification to the SPIRITS client. Since the SCP 
receives the information about the mobility state, this 


involves the C interface. (This is just an extension of the DP 
notification mechanism from the SPIRITS client to the SPIRITS 
gateway). 


The events (which are not DP-related) which need notifications 
are: 


- Location Update in the same VLR service area 

- Location Update in another VLR service area 

- IMSI attach 

- MS initiated IMSI detach 

- Network initiated IMSI detach. 
With this mechanism, the SPIRITS services can use the user- 
profile-based location information. For example, the Internet 
Call Waiting service can re-direct the call to a mobile phone. 

c) Supplementary Services Notification. 

This mechanism makes a SPIRITS server aware of a subscriber 
having invoked one of the following supplementary services: 


Explicit Call Transfer, Call Deflection, Call Completion on 
Busy Subscriber, or Multi-Party. 
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6. 


PINT-related Requirements 


Before a SPIRITS service can be invoked, the relevant IP Host must be 
registered. Thus, Registration is an essential service, which is 
initiated from the IP side. The registration information is 
ultimately used by the PSTN to authenticate the subscriber. 


Depending on the model, this can be done in two ways with the present 
architecture: 


1) The PINT Client issues the appropriate Register message over the 
interface A, which is then passed by the PINT server to the SPIRITS 
Gateway and SPIRITS Client: 


PINT C.: -- Register --> PINT S. [--> SPIRITS Gateway --> SPIRITS 
C.]. In this case the SPIRITS Client (co-located with the service 
control) is responsible for record keeping and the authentication. 


2) The PINT Client issues the appropriate Register message to the 
PINT Server, which then passes this information to the PSTN service 
control "by magic". 


The second model is much easier to handle, because it involves only 
one relevant interface ("A"); however it assumes no interworking 
between PINT and SPIRITS except that the SPIRITS Client finds "by 
magic" that a friendly and expecting IP Host is alive and well. 


Finally, in the event PINT is not implemented, the SIP SUBSCRIBE 
mechanism can be used. 


As noted in the previous section, the existing SUBSCRIBE/NOTIFY PINT 
building blocks [3] must be extended for their use in SPIRITS for the 
purposes of setting DPs/getting DP event notifications. (A more 
general SIP mechanism for the same PINT-introduced block is described 
in [4]; it provides the necessary mechanism for specifying relevant 
events.) Conversely, the same building blocks for the functional 
capabilities can be used in both PINT and SPIRITS protocols. Note, 
however, that in SPIRITS the PSTN notification may arrive without a 
particular subscription to an event (in the case of a statically set 
DP). 


Follow-up on Event Notifications 


The requirements of this section are neither PINT-specific, nor IN- 
specific; their role is to outline the remaining element necessary 
for the delivery of the SPIRITS service, which is the reaction to the 
notification received. 
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In a particular scenario where: 
a) The IP subscriber registers a SPIRITS service; 


b) A call triggering the SPIRITS service is received (and 
notification is sent); and 


c) The call disposition is performed by the end user, the 
signalling flow is demonstrated in Figure 2. 


|----> Registration ----- >| 
SPIRITS |<-- Event Notification <-- | SPIRITS 
Gateway |---> Call Disposition ---->| Client 
V 


Service Control 


V 
SSP 


Figure 2: Sequence of SPIRITS actions 
One of the following actions is required by benchmark services: 
a) Accept the incoming call 
b) Reject the incoming call 
c) Redirect the incoming call 


d) Accept the call via VoIP (this particular item is outside of 
the scope of SPIRITS WG). 


Accordingly, the SPIRITS protocol should define the following message 
types: 


a) S->G: <Accept Call> 
b) S->G: <[Reject Call], [Cause]> 


c) S->G: <[Redirect Call], [Redirection Destination]> 
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8. Methodology 


To determine the MINIMUM SPIRITS protocol vocabulary (i.e., the set 
of messages), the PSTN events associated with each detection point of 
the Basic Call State Model should be examined. To date, the CS-3 
BSCM has the richest set of DPs, although not all switching exchanges 
have implemented it. 


To determine the MINIMUM information available to the SPIRITS client 
(this information is to be carried by the SPIRITS protocol from 
SPIRITS client to SPIRITS server), each DP-specific information 
elements needs to be examined. 


Parameters should be event-specific, the following generic types of 
parameters are expected to be mandatory: 


- timer (for no answer) 
- midcall control info (for mid call) 
- number of digits (for collected information) 
9. Security Considerations 
Overall, the basic aspects of security apply to SPIRITS protocol: 


- Authentication: 
In the communications between the SPIRITS Client and SPIRITS 
Gateway as well as the SPIRITS Gateway and SPIRITS Server, it is 
required that the information be sent between known and trusted 
partners. 


- Integrity: 
It is a requirement that no exchanged data be modified in transit. 


- Confidentiality: 
It is a requirement that any private user information or 
confidential network data be protected by the protocol (typically 
through encryption, for which the protocol should allow a choice 
in the algorithm selection. 


- Availability: 


It is a requirement that the communicating endpoints remain in 
service for authorized use only. 
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In addition, the protocol should support non-repudiation for those 
control messages pertinent to charging the PSTN subscriber. 


As Figure 1 demonstrates, there are two distinct communications 
interfaces, B and C. The B interface is, in general, across the 
public Internet and is thus most vulnerable to security attacks 
resulting in theft or denial of service. The C interface, on the 
other hand is likely to be implemented across a service providers 
intranet, where the security measures should be applied at the 
discretion of the service provider. Even then, because at least one 
IP host (the PINT gateway) is connected to the Internet, special 
measures (e.g., installation of firewalls, although this particular 
measure alone may be insufficient) need to be taken to protect the 
interface C and the rest of the network from security attacks. 


The assumption that the PINT Client and SPIRITS server are co- 
located, dictates that the security considerations for the A and B 
interfaces are exactly same. Detailed security requirements and 
solutions for interface A (and, consequently, B) can be found in RFC 
2848 [3]. 


Possible security attacks can result in both theft and denial of 
services. In addition, such attacks may violate the privacy of a 
PSTN subscriber. For example, with Internet Call Waiting, a 
fraudulent registration (or a manipulation of integrity of a valid 
registration) may force a network operator to provide to an 
authorized party a full log of attempted telephone calls (accompanied 


by the identification of callers). Furthermore, the calls may be 
diverted to wrong recipients (who may further defraud the 
unsuspecting calling party). In this case, the calling party is 


using only the PSTN and thus expecting the security of communications 
that are typical of the PSTN. The PSTN service providers may be 
liable for the consequences of establishing wrong connections. In 
addition, the PSTN service providers may be liable for inadvertent 
divulging of the private information of the subscriber. 


The service and network providers need to review the possibilities of 
the security attacks and prepare the means of protection from them. 
Some of this may be achieved by using the means outside of those 
provided by the protocol itself. For example, administrative 
information (such as statistics collected by PINT MIB or SPIRITS MIB) 
can help in determining violations and thwarting them. As far as the 
protocol is concerned, it must provide the means for authenticating a 
subscriber as well as a session. It must also provide a capability 
to carry encrypted information in its body. 


Faynberg, et al. Informational [Page 14] 


RFC 3298 


SPIRITS Protocol Requirements 


August 2002 


10. Acknowledgements 

The authors are grateful to all participants in the SPIRITS group for 

the discussion that has been shaping this work. Many thanks go to 

Jorgen Bjorkner, Alec Brusilovsky, Jim Buller, Lawrence Conroy, Soren 

Nyckelgard, and John Voelker for their incisive comments. Special 

thanks are to Vijay Gurbani, Dave Hewins, and Kumar Vemuri, whose 

careful, detailed reviews of several versions of this document have 
been particularly helpful in improving its quality. 
11. References 

[1] Slutsman, L., Faynberg, -, Lu, H. and M. Weissman, "The Spirits 
Architecture", RFC 3136, June 2001. 

[2] Lu, H. (Editor), Faynberg, I., Voelker, J., Weissman, M., Zhang, 
W., Rhim, S., Hwang, J., Ago, S., Moeenuddin, S., Hadvani, S., 
Nyckelgard, S., Yoakum, and L. Robart, "Pre-SPIRITS 
Implementations of PSTN-Initiated Services", RFC 2995, November 
2000. 

[3] Petrack, S. and L. Conroy, "The PINT Service Protocol: Extensions 
to SIP and SDP for IP Access to Telephone Call Services", RFC 
2848, June 2000. 

[4] Roach, A.B., "Session Initiation Protocol (SIP)-Specific Event 
Notification", RFC 3265, June 2002. 

[5] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 
Extensions (MIME) Part One: Format of Internet Message Bodies", 
RFC 2045, November 1996. 

[6] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 
Extensions (MIME) Part Two: Media Types", RFC 2046, November 
1996. 

[7] Handley, M., Schooler, E., Schulzrinne, H. and J. Rosenberg, 
"SIP: Session Initiation Protocol", RFC 2543, March 1999. 

[8] Handley, M. and V. Jacobsen, "SDP: Session Description 
Protocol", RFC 2327, April 1998. 

Faynberg, et al. Informational [Page 15] 


RFC 3298 


12: 


Authors” Addresses 


Lev Slutsman 

AT&T Laboratories 

200 Laurel Ave. 

Middletown, New Jersey, 07748 


Phone: (732) 420-3752 
EMail: lslutsman@att.com 


Igor Faynberg 

Bell Labs/Lucent Technologies 

Room 4D-601A, 101 Crawfords Corner Road 
Holmdel, New Jersey, 07733 


Phone: (732) 949-0137 
EMail: faynberg@lucent.com 


Jorge Gato 

Vodaphone 

Avda de Europa, 1. 

28108 Alcobendas (Madrid). Spain 


Phone: +34 607 13 31 10 
Fax: +34 607 13 30 57 
EMail: jgato@airtel.es 


Hui-Lan Lu 

Bell Labs/Lucent Technologies 

Room 4C-607A, 101 Crawfords Corner Road 
Holmdel, New Jersey, 07733 


Phone: (732) 949-0321 
EMail: huilanlu@lucent.com 


Faynberg, et al. Informational 


SPIRITS Protocol Requirements 


August 2002 


[Page 16] 


RFC 3298 SPIRITS Protocol Requirements August 2002 


13. Full Copyright Statement 
Copyright (C) The Internet Society (2002). All Rights Reserved. 


This document and translations of it may be copied and furnished to 
others, and derivative works that comment on or otherwise explain it 
or assist in its implementation may be prepared, copied, published 
and distributed, in whole or in part, without restriction of any 
kind, provided that the above copyright notice and this paragraph are 
included on all such copies and derivative works. However, this 
document itself may not be modified in any way, such as by removing 
the copyright notice or references to the Internet Society or other 
Internet organizations, except as needed for the purpose of 
developing Internet standards in which case the procedures for 
copyrights defined in the Internet Standards process must be 
followed, or as required to translate it into languages other than 
English. 


The limited permissions granted above are perpetual and will not be 
revoked by the Internet Society or its successors or assigns. 


This document and the information contained herein is provided on an 
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
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